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BILL NO. S-82-02- ’ 


SPECIAL ORDINANCE NO. S- MzJW 

AN ORDINANCE approving City Utilities 
Purchase Order No. A-010412 with American 
Management Systems, Inc., for an Auto¬ 
mated Financial Accounting System for 
Fort Wayne City Utilities. 

BE IT ORDAINED BY THE COMMON COUNCIL OF THE CITY OF 
FORT WAYNE, INDIANA: 

SECTION 1. That City Utilities Purchase Order No. A- 

101412, dated February 5, 1982, between the City of Fort Wayne, 

by and through the City Utilities Purchasing Agent and the Board 

of Public Works and American Management Systems, Inc., for: 

an Automated Financial Accounting 
System for Fort Wayne City Utilities, 


at a cost of $167,500.00, all as more particularly set forth in 
said Purchase Order, which is on file in the Office of the 
Department of Purchasing and is by reference incorporated herein 
and made a part hereof, be and the same is in all things ratified 
confirmed and approved. 


SECTION 2. That this Ordinance shall be effective upon 
passage and approval by the Mayor. 











BRADBURY 

BURNS 




GiaQUINTA 

NUCKOLS 


SCHOMBURG 

STIER 
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^ —Zpr 




Passed and adopted by the Common Council of the City of Fort Wayne, 

Indiana, as fe ONTNG MAP) -(GF.NF.Rfllr)- (ANNEXATION) (SPECIAL) 

;(A PPJRQPRI AT ION) ORDINANCE (R ESOL UTI ON NO. 

on the _ ,-Z) r-3 d ay of _ f jg 

ATTEST: (SEAL.) 

CHARLES W. WESTERMAN- CITY CLERK PRESIDING^OFfTcER-“— 


Presented by me to the Mayor^f the City of Fort Wayne, Indiana, on 

the _ cgj/^L, _day of 19 diu . at the hour of 

_ .// ' _o'clock sM.^E.S.T. 

















































































S-82-02-05 


BILL NO. 

REPORT OF THE COMMITTEE ON CITY UTILITIES _ 

WE, YOUR COMMITTEE ON City Utilities _ T0 whom WAS REFERRED AN 

ORDINANCE aonroving City Utilities Purchase Order No. A-010412 
with American Management Systems, Inc., for an Automated 
Financial Accounting System for Fort Wayne City Utilities 


HAVE HAD SAID ORDINANCE UNDER CONSIDERATION AND BEG LEAVE TO REPORT 
BACK TO THE COMMON COUNCIL THAT SAID ORDINANCE ✓•^"'^ ASS. 

PAUL M. BURNS - CHAIRMAN 
MARK E. GiaQUINTA - VICE CHAIRMAN 


JAMES S. STIER 


JANET G. BRADBURY 


ROY J. SCHOMBURG 


r ' 



- ha; — V V. WESTERMAN, CITY CLERK 




























DEPARTMENT OF PURCHASES 
NUMBER ONE EAST MAIN STREET. ROOM 940 
FORT WAYNE, IN 46802 


A-01 041 2 


MAIL ALL CORRESPONDENCE, CLAIM VOUCHERS, ETC., TO: 

City Utilities Operations 
One Main Street 
[_Fort Wayne IN 46802 

r 

American Management Systems, 

1777 N. Kent Street 
^ Arlington VA 22209-2166 

DELIVER TO: DEPART- 



CITY CONTROLLER 


OF THE ABOVE PURCHASE IS FULLY COVERED 

THE ABOVE FUNDS AND THAT THE EXPEND- 
' AUTHORIZED AND APPROPRIATED. 


D APPROVED REQUISI 




DIRECTOR OF PURCHASES 


ORIGINAL (1) 





























MEMORANDUM 


To: 


Board of Public Works 


Date: 02/05/82 


From: Aaron M. Gluck, Director of Purchases 


Subject: Bid Reference Number 0637 


Attached are copies of the Bids received for an Automated Financial Accounting 
System for the Fort Wayne City Utilities. Purchase Order Number A-010412 has been 
assigned to American Management Systems, Inc. 

The bid received from American Management Systems, Inc. was the only bid re¬ 
ceived. After close evaluations of the above referenced bid, and a review of 
other systems available, the MIS Committee, Utility Accounting Department, Controllers 
Office and the Data Processing Department agree that this system is the best 
system available for the funds available. 

Please include the attached supporting information when this ordinance is 
submitted to City Council for Approval. Also, please insure that no confirming 
Purchase Order number is given to American Management Systems, Inc. until 
Purchasing receives written confirmation of Council Approval. 



Aaron M. Gluck, Director 
Department of Purchases 


OF PVWK WORKS 



FEB 0j 1932 U 






CflTY OF FORT WAYNE 

DEPART:,JE^T OP PURCHASES 
Uijhb&r One .Main St., Ft. Wayne, Ind. 46802 
INVITATION 

eoodl*Jo«fc oq 


Page. 


Ref. No. - 637 

Date 12/16/81 


AARON M. GLUCK 


DEPARTMENT OF PURCHASES 


Room 940^ .Number One Main St., Ft. Wayne, Ind.’ 46802 


REQUIRED FOP. DELIVERY TO: 


Department 
or Division:_ 


DATA PROCESSING 

mam sire ' et— 


Date wanted i" 4 "* 


Fund 

Appropriation Ko. _ 


PORT WAYNE IN 4&802 


RETURN ORIGINAL TO THE CITY—RETAIN DUPLICATE COPY FOR YOUR FILS ' 
Clashes ■ 

' Time of Bida_ 


JANUARY 4, 1982 at II a.a. 


TAX EXEMPT (Unless otherwise indicated) 


FINANCIAL MANAGEMENT SYSTEM, SOFT WARE PROPOSAL FORMS 


AFFIRMATIVE ACTION: ON FILE 


Bid 3o»J revarwi □ 


5 percent 


- Perform xncs Bond Q 


. IiJtracCoa r-a No. 15 era Mr»™ i!6 2mt»£. 

cash, discount if paid withi n— - -days from delivery and acceptance of gtxxls or completion of: 


PROPOSAL OP. BID 


Delivery of any or all of the items or completion of services indicated shall be made within_daj 3 from recdpi 


IMPORTANT 


r 


n 


U K Milas tx^ar la ts* 
xberr 

£y» Hw»i 


- 


ci » cciMV lk U 


L 


Americ5^Managanenf°^|^ems, Inc. 

1777 N. Kent Street 


. ^XliiiaLoP->..y^._ 2220 ^- 2166 _ 












































Section I 

PROPOSAL COST SUMMARY 
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TO: City of Fort Wayne 
City-County Building 
One Main Street 
Fort Wayne, IN 46802 
ATTN: Aaron Gluck 


The undersigned, being familiar with the requirements of the City of 
Fort Wayne Financial Management System Request for Proposal, proposes to 
furnish products and services to the City in accordance with that request. 

The summary below reflects projected City expenses for system acqui¬ 
sition and implementation. It may include cost estimates for items which 
the undersigned does not propose to furnish and which must be obtained 
from another source; these items are annotated accordingly. Items not so 
marked will be furnished by the undersigned at indicated costs. 


ITEM 

1. Application software and vendor- 
furnished support software, 
license.* 

2. Duration of application software 

warranty (months) 12 _ 

3. Maintenance for application soft¬ 
ware for one year beyond end of 
warranty. 

4. Vendor on-site implementation 
support: 

User and DP training 
Other on-site support 

5. Other costs for City implementation. 

6. TOTAL 


COST 


$160,000 


10% of then cost 


included in Item I 


included in Item I 


material and computer time 
travel expenses 

$160,000 


* Provide detail on other options, including annual license cost, in 
Section 4 of Cost Volume of RFP response. If software is available 
only under shorter term lease, include that cost in this summary and 
indicate the term. 


1 


1 











In submitting this bid, it is understood that the right is res- 
the City of Fort Wayne to reject any and all bids, and to waive an; 
malities in bidding. 

The undersigned further states that this proposal is made ir 
and is not founded on, or in consequence of, any collusion, agre 
understanding between himself or any other interested party. 


OFFICIAL ADDRESS: 


American Management Systems, Inc. American Manar 


1777 North Kent Street 



Signature of 


Arlington. VA 22209-2166 


Vice Pres' r 

Title 


PHONE: (7031841-6000 


December 


Date 











Section II 

Itemized Acquisition Cost Breakdown 


Application Proposal 

Volume I described the proposed system LGFS PLUS and the subsystems- 
Job Cost Accounting and Performance Measurement. The software packages 
are offered to Fort Wayne on a long term license basis. The application 
packages, staff days and license fee are listed below. 


Application Package 

AMS Staff Days 

License Fee 

LGFS PLUS 

40 

$ 99,500 

Online System 

10 

25,500 

Performance Maintenance 

3 

10,000 

Job Cost Accounting 

5 

25,000 

TOTAL 

58 

$160,000 

The only additional cost is for travel expense, 
-is included in the license fee. 

First year maintenance 


3 




Section III 


Future Maintenance Cost 


The maintenance fee for the.first full year of the application 
software is included in the license fee. Subsequent 12 month main¬ 
tenance service is optional at 10% of the then current license fee 
for the options under service. 


4 



Sectfon IV 


A. Cost of Options 

The cost for all options described in our proposal are detailed in 
Section 2 of this volume. 

AMS is able to provide additional consulting and programming if 
required at $60.00 per hour rate. Onsite work and travel expenses are 
additional. 

B. Payment Terms 

1. '25% of license fee upon execution of license agreement and 
delivery of Management Guide, Procedures Manual, Operations 
Guide and Data Entry Guide. 

2. 25% of license fee upon delivery of software. 
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SECTION 1 - GENERAL INFORMATION 


1. Purpose of RFP : This request solicits proposals to furnish the 
City of Fort Wayne with an automated accounting and financial management 
system. The City seeks software capable of being installed on the City's 
IBM 4331 Group 2. The City anticipates meeting its financial management 
requirements in Calendar Year 1982 starting in January, 1982 through 
acquisition of a software package if that is determined to be feasible. 

If so, it is the City's intent to make a selection based on responses to 
this RFP, without again soliciting bids. 

2. Background Information : 

a. Hardware and System Software : The City now provides DP sup¬ 
port using an IBM 4331 Group 2 computer with DOS operating system. 
Approximately 50 terminals are used to support development and production 
applications. The system currently has 3 megs of core. It is operating 
under CICS release 1.41, but it is expected to very shortly function under 
version 1.5. 

b. Application Software : Application systems in production 
status include payroll. Utility billing. Civil City accounting, purchasing/ 
warehousing, and miscellaneous applications. These systems were developed 
primarily in-house and are written in COBOL. The Payroll/Personnel may 

be replaced by modules of the system should the City seek to obtain the 
sdme in the near future. 

3. Scope of Proposed Project : The City requires a system providing 
comprehensive and fully integrated support for general accounting, pur¬ 
chasing, disbursements, expenditure and revenue monitoring and budget 
preparation. It is highly desirable that other modules be available which 
would meet the City's needs in the areas of financial planning, payroll/ 
personnel and Utility billing. 

4. Project Funding : This project will be proposed to the City 
Council of the City of Fort Wayne in January, 1982. Proposals responding 
to this RFP will be timely with respect to preparation of the proposed 
Utility budget for Calendar Year 1982. Any contractual agreement concern¬ 
ing payments must be conditional on approval of corresponding funds as part 
of the respective year's budget appropriation. 
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5. Schedule of Activities : 

ACTIVITY DATE 

Release of RFP to Vendors 12/15/81 

Letter of Intent requested by 12/23/81 

Proposals Due 1/05/82 

Completion of Evaluation and Tentative 
Selection 1/12/82 

Introduction to City Council 1/12/82 

Formal Approval of Project and Vendor 
Notification Approx. 2/01/82 

Execution of Contract 2/01/82 

Initial Operational Capability (1) 5/01/82 


]_/ Target date is critical, and vendors' proposed dates will be a factor 
in proposal evaluation. 
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SECTION II - INSTRUCTIONS AND CONDITIONS FOR PROPOSAL SUBMISSION 


1. Inquires : General questions concerning this RFP may be referred to 
City of Fort Wayne, ATTN: Aaron Gluck, Purchasing Director, City-County 
Building, One Main Street, Fort Wayne, Indiana 46802. Phone (219) 423-7037. 
Questions concerning specific functional requirements, including those de¬ 
tailed in Appendix A, Capabilities Checklist, should be referred to 

Alan Zirkle, Director of Operations, (219) 423-5146. 

2. Letter of Intent : It is requested that vendors who intend to sub¬ 
mit proposals so notify the City of Fort Wayne in writing by December 23, 
1981. The letter of intent should include: 

a. A list of at least five (5) governmental agencies using the 
proposed software. It is desirable that these agencies be local governments 
with requirements similar to City of Fort Wayne. For each of these user 
references, please provide address, name of knowledgeable person to contact, 
phone number, date system became operational, and comments noting agency's 
software. 

3. Exceptions to RFP Specifications : It is intended that this RFP 
describe City requirements and response format in sufficient detail to 
secure comparable bids. However, bidders are not precluded from submitting 
proposals which differ from the described specifications. Such proposals to 
be in the interest of the City, they will be considered. 

4. Implied Requirements : All products and services not specifically 
mentioned in this RFP, but which are necessary to provide the functional 
capabilities described by the vendor, shall be included in the bid. 

5. Vendor-supplied Materials : Any material submitted by a vendor 
shall become the property of the City unless otherwise requested at the time 
of submission. Any material that is to be considered as confidential in 
nature must be so marked. 

6. Optional Features : Proposals may contain description of minor 
options or alternatives which may be available to the City; these descrip¬ 
tions must clearly identify such items as options, and indicate any cost 
impact. Base costs shown in the Proposal Cost Summary are to exclude costs 
of such options. The cost data volume of each response should identify and 
itemize separately and actual cost impact of such options. 

7. Training : Proposals shall include all required on-site training of 
user and DP personnel, including technical training in the use of any pro¬ 
posed systems software. 
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8. Multiple Proposals : Any major variations or alternatives, such 
as language other than COBOL, should be presented as additional proposals. 

Such secondary proposals should follow the same instructions and format as 
the primary proposal, but need include only information which differs from 
it. 

9. Contract Development : If it accepts a proposal, the City intends 
to enter into a contractual agreement with the vendor providing the selected 
system. Contract discussion and negotiation will follow selection of the 
apparent successful bidder. Because of the complex nature of this acquisi¬ 
tion, it is unlikely that an award will be made directly on the basis of pro¬ 
posal content. The City reserves the right to negotiate further with one or 
more vendors. The content of the RFP and the successful bidder's proposal 
will become an integral part of the contract, but may be modified by pro¬ 
visions of the contract. Vendors must be amendable to inclusion in a contract 
of any information provided either in response to this RFP or subsequently 
during the selection process. Vendors are requested to submit current con¬ 
tract forms with their response for review by the City. 

10. Proposal Submission : Proposals are to be submitted in accordance 
with the instructions in Section IV, by the date specified in Section I, 
para 6 (Schedule of Activities). 
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SECTION III - REQUIREMENTS FOR PROPOSED SYSTEM 


1. General Requirements : 

a. Preceding paragraphs covering purpose of the RFP, current appli¬ 
cations, scope of project and acceptable alternatives are descriptive of gen¬ 
eral requirements. 

b. The system acquired must have a capability for on-line data 
entry, file maintenance, transaction editing, and inquiry. The system must 
also have the ability to process transactions in an off-line batch mode so 
as to better manage computer resources. 

2. Capabilities Checklist : Appendix A is a checklist of desired sys¬ 
tem features. The checklist is to be completed by vendors and returned with 
proposals. 

3. Software Requirements : 

a. The City contemplates a phased implementation of the acquired 
system. The first phase must include, but need not be limited to, purchas¬ 
ing/procurement, statistical reporting, project and program reporting, and 
budget preparation. Of less urgency are requirements for fixed asset account¬ 
ing, and payroll/personnel. All components of the system must be fully inte¬ 
grated when implemented. 

• b. Although the implementation plan may reflect deferred acquisi¬ 

tion of some software components, the vendors cost data (Section IV, Para¬ 
graph 2.b) and other parts of the response must address all functional 
requirements outlined in the RFP. 

c. Documentation must include instructions for users, computer 
operators, programmers, and systems administrators. 

d. Full maintenance documentation is desired for all vendor-pro¬ 

vided software, to include narrative and graphic descriptions and program 
source listings. Programs should be annotated and formatted to facilitate 
maintenance. ' 


e. Note the vendors intent to support their software application 
during the seven (7) years following installation date. 

f. The program language should be COBOL. Any variations should 
be specified on Page 4, paragraph 8, Multiple Proposals. 
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4. Acceptance Test : An acceptance test will be developed by the City 
with support from the selected vendor. Test objectives will be to determine 
that the delivered system interfaces appropriately with all other of the 
City's systems and performs adequately, and that it meets the City's require¬ 
ments established during selection. Results will be used to determine the 
vendor's satisfaction of contractual obligations for delivery of an opera¬ 
tional system. 
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SECTION IV - VENDOR RESPONSE FORMAT AND CONTENT 


1. Letter of Intent : See Section II, Paragraph 2. 

2. RFP Response : Proposals should be presented in four (4) separate 
volumes organized as described below. Adherence to this format is import¬ 
ant to the City's evaluation process. 

a. Volume I - Descriptive Information : This volume should stand 
alone as a description of the proposal and not require reference to other 
materials. It should contain the following sections only, in the sequence 
listed. 

Section 1 - Proposal Summary : A non-technical summary pro¬ 
viding a management-oriented overview of the proposal. It should identify 
software modules and the functional capabilities they will provide, pro¬ 
ject phasing and organization, vendor support, and City responsibilities 
and resources required. Do not include cost data in this volume. 

Section 2 - Proposed Approach : Describe the proposed approach 
to providing the City with the required capabilities. Include sufficient 
detail for technical evaluation. It is not necessary to repeat information 
contained elsewhere in Volume I; reference other sections as appropriate. 

Section 3 - Project Organization : 

(1) Describe a recommended time-phased implementation plan 
reflecting major tasks and milestones in planning, preparation, training, 
testing, and acceptance. Describe City responsibilities, and all resources 
required. 

(2) Describe the scope and level of effort of vendor sup¬ 
port for the project implementation. Identify by name the personnel who 
will be assigned to provide the on-site support, and describe their back¬ 
grounds and pertinent experience. Identify any sub-contractors to be em¬ 
ployed, and their role. 

Section 4 - Capabilities Checklist : Include a copy of the 
checklist provided as Appendix A to this RFP, completed in accordance with 
accompanying instruction. 

Section 5 - Software Description : 

(1) Provide any additional software information necessary 
to show satisfaction of City requirements, or to describe features of 
potential value to the City but not specified as requirements. 
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(2) Identify any requirements for new systems software or 
development software; if any of these are not included in the bid, so indi¬ 
cate. 


Section 6 - Client References : To augment references provided 
with the letter of intent, provide a listing of other installations of the 
proposed software, with operational dates and points of contact. 

Section 7 - Other Information (Optional) : Include other in¬ 
formation considered necessary to an understanding or evaluation of the pro¬ 
posal. Attention is invited to the evaluation criteria listed in Section V 
of the RFP. Limit to six (6) pages. 

b. Volume II - Cost data : This volume should contain all cost 
information for the proposal. Prices must be valid through March 1, 1982. 

Section 1- Completed Proposal Cost Summary : (A blank copy is 
attached as Appendix C to the RFP.) 

Section 2 - Itemized Acquisition Cost Breakdown : Provide an 
itemized breakdown of costs reflected in the Proposal Cost Summary: Show 
license fees and one year maintenance costs for all required application 
software by modules; estimated costs of any site preparation; purchase and 
maintenance costs for all required new systems software and program develop¬ 
ment software; costs of vendor on-site support for project implementation, to 
include training; any other costs which the City will incur in implementing 
the project. Show all discounts for which the City is eligible. Show sub¬ 
totals and totals corresponding to those included in the Proposal Cost 
Summary. 

Section 3 - Future Maintenance Costs : Itemize maintenance costs 
for one full year. Include maintenance for: (a) all application software, 
and (b) support software provided by vendor. 

Section 4- Cost of Options : Provide detailed cost information 
for any optional program modules or other items described in the response, 
and now included in Section 1 and 2. Indicate rates charged for optional 
consulting and programming work, both on-site and at vendor's location. Show 
fee for perpetual license for each software module. 

Section 5 - Vendor Financial Status : Provide information to sup¬ 
port an evaluation of the Vendor's current financial status. 

c. Volume III - Sample Contract and Documentation : 

Section 1 - Sample Contract : Provide for City's review a sample 
copy of Vendor's contrct forms. 

Section 2 - Sample Documentation : Provide sample documentation 

as follows: 
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(1) A program source listing v/hich illustrates typical pro¬ 
gram structure and annotation. 

(2) Portion of user manual describing detailed procedure 
for year-end closing of accounting files, and related user capabilities. 

(3) Portion of operations manual. 

(4) Documentation describing recovery and restart proced¬ 
ures to be employed in the event of accidental destruction of general ledger 
account records. 


(5) Portion of data entry instructions. 

d. Volume IV - Additional Material (Optional) : Include in this 
volume any desired additional information or promotional materials. 

3. Number of Copies : Volumes I and II should be provided in one copy. 
Volumes III and IV and one copy. Copies should be packaged together in one 
separate sealed envelope marked "SEALED BID FOR FINANCIAL MANAGEMENT SYSTEM". 
All volumes, including this sealed envelope, may then be forwarded in one 
container. Address responses to: 

City of Fort Wayne 
ATTN: Aaron Gluck 
Purchasing Department 
City-County Building 
One Main Street 
Fort Wayne, IN 46802 
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SECTION V - PROCESSING OF RESPONSES AND APPROACH TO AWARD OF CONTRACT 


1. Opening of Bids : Sealed proposals will be accepted until 12:00 noon 
on the "Proposals Due" date as shown in the Schedule of Activities (Section I, 
Paragraph 6). Immediately thereafter, all bids will be publicly opened and 
the Proposal Cost Summary read aloud in the presence of any bidders in the 
Board of Works Hearing Room. Bidders are invited but not required to attend 
the bid opening. 

2. Evaluation of Responses : 

a. Proposals will first be examined to eliminate those which do not 
respond to stated requirements, and to identify the several most promising 
responses. 

b. The most promising reponses will be evaluated in detail. Systems 
documentation and additional information may be sought from vendors. Vendors 
may be asked to present and explain their proposals at management and technical 
levels. The proposal which then appears most favorable to the City will be 
compared to other proposals of lower cost. This analysis will examine differ¬ 
ences in costs and benefits; cost differences must be justified by the value 
of the greater benefits. 

c. The detailed evaluation will result in selection of an apparent 

successful bidder. Contract negotiation then will be started as soon as pos¬ 
sible. (Attention is invited to Section II, paragraph 9 , Contract Develop¬ 

ment.) If a contract for any reason cannot be negotiated, another vendor will 
be selected as the apparent successful bidder. 

3. Evaluation Criteria : Factors to be considered in evaluation will 
include: 


a. Ability of vendor to satisfy functional requirements and other 
objectives. Focus is on attributes of the proposed application software. 

b. Total system costs, including costs of vendor's products and 
services, system software purchase and maintenance costs, installation costs, 
and cost to City of resources required to support installation and operation 
of the system. 

c. Vendor's ability and willingness to make needed software modifi¬ 
cations as part of the proposed implementation. 

d. Anticipated level, timeliness and quality of vendor's support 
during and after planning and implementation. 
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e. Vendor's implementation plan and personnel assigned. 

f. Vendor's ability to meet an operational readiness by an agreed- 
upon date. 

g. Time required for installation of an operational system. 

h. Ease vyith which the City can effect future software changes. 
(Primarily dependent on completeness and quality of program maintenance docu¬ 
mentation.) 

i. Favorable assessment, by other clients with similar needs, of 
the vendor's proposed products and services. 

j. Characteristics of support software. 

k. Vendor's experience in installing proposed software. 

l. Vendor's experience with local governments and other governmental 

users. 

m. Vendor’s general qualifications including such factors as organ¬ 
ization size, financial position and time in business. 

n. Availability from vendor of integrated software modules addres¬ 
sing a broad range of financially related applications. 

4. City's Option : The City reserves the right to reject any or all bids, 
to waive any informalities in the bids received, and to accept the proposal 
deemed most advantageous to the City. 
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APPENDIX A 

CAPABILITIES CHECKLIST 


CITY OF FORT WAYNE 
REQUEST FOR PROPOSAL 


FINANCIAL MANAGEMENT SYSTEM 
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APPENDIX A 

CAPABILITIES CHECKLIST 


Vendors are requested to use this checklist to describe the proposed 
software's specific functional capabilities. The purpose is threefold; 

(a) to assist the City in identifying areas on which to focus in later dis¬ 
cussions; (b) to support efficient comparison and evaluation of proposals; 
(c) to indicate general system requirements to vendors. Completion of the 
checklist in accordance with instructions below is essential to satisfy 
the first two of these purposes. 

Taken collectively, capabilities listed do indicate general require¬ 
ments. Individually, the items vary in importance. The importance of many 
depends on the approach which a proposed system takes in handling implied 
broader needs; that importance can be determined only in the context of a 
specific proposal. Hence, vendor responses to individual checklist items 
will not be evaluated in isolation, or without considering total capabilit¬ 
ies described in a proposal. 

Capabilities are grouped by category as a matter of convenience. They 
are listed in the category to which they appear most closely related. Some 
are applicable to more than one category. The list following each category 
heading should not be construed as all-inclusive. 

Vendors should make entries in the "Vendor Status" column as follows: 

N - (Mow) Full capability is now provided by the proposed software. 

A - (Add) Full capability not provided now, but will be added prior 
to system installation at no additional cost. 

P - (Partial) Will be provided only in part, or not as described. 
(Please explain by comment.) 

X - (No) Not provided. (May explain by comment.) 

Comments to explain P and X entries should be inserted below the cor¬ 
responding items. A continuation sheet may be used. 

Questions concerning specified user-oriented functional capabilities 
may be referred to Alan Zirkle, Director of Operations, (219) 423-5146. 


- 14 - 

• ' Capability 

Vendor 

Status 

GENERAL: 

1. All modules of the system should employ CRT terminals for on-line: 

a. Transaction entry, correction, and editing 


2. b. File maintenance 


3. c. Initiation of report production and other ba'tch jobs (through text 
editor located on-site) 


4. d. Inquiry 


5. Terminal use based on a "menu" approach, whereby user selects functions to 
be performed based on displayed information. 


6. Minimize user requirements for input form preparation and data entry, 
through- use of tables, a date base, or by other means. 


7. Provide for one-time entry of data supporting internal double entry fund 
accounting. 


8. Support reporting by fund, organizational element, appropriation, program, 
and project or grant. 


9. Modified accrual accounting, expenditures on accrual basis, revenues on 
either cash or accrual basis as specified by user. 


10.. User-defined fiscal year-end. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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' ' Capability 

Vendor 

Status 

11. Provide security facilities allowing user to selectively limit access to 
files and programs on the basis of requester's ID, passwork, terminal used 
and function performed (read vs. write). 


12. Provide full backup capabilities and facilities for recovery and restart 
following system or program failure, or detection of a data exception. 


13‘. Provide capability to use a transportable storage medium to permit off-site 
storage of backup files. 


14. Updating to occur as entered or at least on a daily basis. 


15. Transaction detail listings to be available daily, monthly, year-to-date, 
and potentially 1ife-to-date, with variable formats. 


16. Provide facilities to support detailed auditing in accordance with 

established procedures. Requirements include a sound audit trail, recon¬ 
struct! ble data and adequate record retention. 


17. Provide a capability for departments which receive revenues to enter 

revenues projections. These will project the amount and time of receipt 
of anticipated revenues, by line item, for the current fiscal year, and 
for future periods as required by other subsystem. Capability to update 
the projection is required. Periodic revenue reports are required which 
. allow ready comparison of actual with projected revenues. Reports show¬ 
ing department and municipal consolidations, and consolidations by item 
categories, are also required. 


18. Provide a capability for each budgeting department to enter an expendi¬ 
tures plan. This plan will project the timing and amount of expenditures 
for each budget item for the current fiscal year, and for future periods as 
required by other subsystems. A capability to update projections is re¬ 
quired. Periodic expenditures reports are required allowing ready compari¬ 
son of actual with projected expenditures. Department and city-wide 
consolidations, and consolidations by category also are required. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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. • Car-ability 

Vendor 

bcatus 

19. Support the expenditures components of Budget Preparation, Cash Flow 
Management, and Financial Modeling and Planning functions. (A major 
consideraiton is collection of projected expenditures data for future 
periods as required to support these funci tons, in the proper form 
and level of detail.) 


20._ Provide capability to easily modify reporting structures. 


21. Provide for recording transactions and costs at "cost center" level and for 
accumulating to higher reporting levels. 


22. Provide on-line, high volume maintenance capabilities for account additions 
and deletions, and specification of exception parameters and report options. 


23. Accomodate the new 9-digit ZIP code. 



N=Now, A=To be added, P^Partial or not as described, X=Not provided 
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'* .* . Capability 

Vendor 

Status 

CONTROLS: 


24. 

Batch controls on all transaction groupings. 


25. 

Provide a batch balance report allowing comparison of manual and machine- 
developed totals for transactions. 


267 

Internal balancing of all funds. 


27. 

Out-of-balance batches to reject batch and perform corrections on-line. 


28. 

Provide automated checks for proper sequence of jobs in multi-job runs. 


29. 

Data files to contain control record counts and dollar totals which are used 
for verification of processing. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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•..* Capability 

Vendor 

Status 

VALIDATION, EDITING, CORRECTIONS: 

30. Provide for validation, editing and correction of input data before it is 
entered into ledger files. 


31. Provide positive verification of account number input (matching key) prior 
__ to ledger-file update. 


32. Edit all transactions, both financial and non-financial. 


33. Provide capability to produce printed batch and/or transaction listings 
which clearly identify errors. 


34. Provide for editing to be ocmpleted prior to updating of ledger and table 
records to insure only clean data is used. 


35. Provide error recycle file to reduce error correction effort, and allow 
correction input on error fields only. 


36. Automatically create appropriate entries to maintain balance of the system, 
adjusting for erroneous transactions rejected during edit phase. 


37’. Validation capability for maintenance changes showing "changed from 
to " • 


38. Validate each accounting transaction for balance before accepting. 


39. Provide for on-line correction and/or modification of previously made 
entries by authorized users. 

_ 



* K=Now, A=To be added* P=Partial or not as described, X=Not provided 
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, - v « Capability 

Vendor 

Status 

PROJECT OR GRANT ACCOUNTING: 

40. Project can be predefined to one or more cost centers. Activity coded to 
the cost center automatically posted to the project. 


41. Revenue, expenditures, and encumbrances reported by project. 


42. -'User-defined accumulation of similar projects to one higher level. 


43. Automatic rejection of attempted overexpenditure of remaining project 
budget- 


44. Optional project chart of accounts. 


45. Project year-end independent of fiscal year-end. 


46. Report project status for current month, YTD, and inception to date. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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, - '■< Capability 

Vendor 

Status 

PROGRAM ACCOUNTING: 

47. Support a user defined program structure independent of organization and 
appropriation. 


48. Report revenues and expenditures by program on the same report. 


ORGANIZAITONAL (RESPONSIBILITY) REPORTING: 

49. Provide the capability for a user-defined organization structure. 


50. Provide a variable number of detail cost centers within any organizational 
element. 


51. Report revenues and expenditures on the same report by lowest-level 
responsibility areas. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 





















, • Capability 

Vendor 

Status 

UNIT OF SERVICE AND STATISTICAL REPORTING: 


52. Provide a capability to support performance measurement through collection 
of non-monetary statistical data associated with specific accounts or 
line items. For example, permit collection of number of people served 
and miles traveled by the bus system, and the work time used and number 
of inspections completed for the City fire inspection program. 


53. Provide capability for unit-of-service cost reporting, and for recording 
--and reporting units of service at any level of organization, program, and 
project or grant. 


54. Support reporting of multiple units of service at cost center or any level 
of organization or program (actual vs. budget, with unit cost calculated.) 


55. Provide automatic roll up of units of service to any level of organization 
or program. 


56. Provide ability to post non-financial transaction data for use by the 
general ledger subsystem, and other subsystems as required, to support 
performance analysis. 



* N=Now, A=To be added, P^Partial or not as described, X=Not provided 
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Capability 

Vendor 

Status 

SYSTEM-GENERATED REPORTS: 

57. Generate reports reflecting current expenditures and encumbrance/obligations 
in relation to corresponding budgeted allotments and/or appropriations. 
Reports should be produced monthly or, optionally, on user request. 


58. Provide both historical and current data to the lowestbudget unit as de¬ 
termined by the user, and summarize data to each organizational level above 
the budget unit. 


59. Statements and/or reports to be issued to Department/Divisions/Funds should 
be structures by lowest organizational unit and "rolled-up" to desired 
organizational level. 


60. Report at user-specified organizational levels within Program and/or 
Project/Grant, with roll-up summaries. 


61. Report sources of funds for each organizational level within Program or 
Project/Grant. 


62. Permit all reports, routine and exception, to be produced automatically or 
on request, at the user's option. 


63. Allow for a user-specified, flexible reporting schedule, with capability to 
produce reports: 


(a) Daily 

(b) Weekly 

(c) Monthly 

(d) Quarterly 

(e) Annually 
- (f) On-call 


64. Report all transactions on formatted reports. Allow user to select report 
sequence, totalling and level of detail to be printed.. 


65. Provide a chart of accounts report on user request. 



K=Now > A=To be added, P=Partial or not as described, X=Not provided 
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Capability' 

Vendor 

Status 

INQUIRY/REPORT WRITER CAPABILITY: 

66 Provide facilities to generate periodic and ad hoc reports using a flexible, 
user-oriented report’writer capability, with output to termincal or printer. 


67. Permit retrieval of transaction and file record data using multiple selection 
cri teria. ~ 


68. Provide selective user access to all appropriate-on-line files or sections of 
the data base. 


69. Report writer able to perform the following calculations: 


— Account add, subtract, divide, multiply 

— Calculate change and percent of change 


70. Computations to take place immediately so that the result can be used by later 
calculations employed for the same report. 


71. Permit each calculation to contain multiple factors, including user-defined 
constraints. 


72. Allow the user to define formats, and compile data fields and description 
.fields in a desired display format. The user should be able to display 
accounts or cost centers or time periods in line sequence or in column 
-sequence. 


73. Allow the user to control the printed line/column total line. Permit 

multiple accounts to be summarized and reported on one report line or column, 
without having to specify a calculation. Permit a total lin.e to be created 
by'adding or subtracting a series of detail accounts. 


74. Report writer able to provide run time options allowing the user to alter: 


— The sort key 

— Report frequency 

— Sub-totalling options 

— Choice of summary or detail 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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’ Capability 

Vendor 

Status 

IN0U1RY/REP0RT WRITER CAPABILITY, continued: 


75. Permit user to define report title and columnar captions. 


76. Permit user to define different data line formats within the same report. 


77. Permit user to determine the number of print lines per page. 


78. Permit user to specify the spacing between columns. 


79. Permit user to designate specific fields as sort keys. 


80. Permit at least five separate levels of subtotals within the body of the 
report. 


81. Permit total lines to be formatted differently than data lines. 


82. Permit user to control the spacing between print lines. 


83. Provide user option to suppress the printing of zero value lines or columns. 


84. Headers and titles should be repeated automatically on continuation pages, 
and number incremented on multiple page reports. 


85. Provide option to produce output in report format or in transaction format. 


86. Permit production of multiple reports in one report cycle. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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. '■ ' Capability 

Vendor 

Status 

INQUIRY/REPORT WRITER CAPABILITY, continued: 


87. Allow the user to specify which cost centers and hierarchy units will be 
printed. 

88 . Allow the user to sort reports to specified output devices for storage or 
printing. - ... 


89. Provide ability to produce monthly reports for any prior month in current year 
or the previous year. 


90. Provide ability to show multiple months' data on the same report (i.e., 

Jan., Feb., Mar., ...Dec.). 


- 



* N---Now, A=To be added, P=Partial or not as described, X=Not provided 













Capability 

Vendor 

Status 

GENERAL ACCOUNTING/GENERAL LEDGER: 


91. Collect financial and statistical data to support the General Ledger 
Subsystem. 


92. Post transactions to the General Ledger, and provide a record of these 
transactions. 


93. Provide data necessary to continuously monitor the City's financial position. 


94. Provide capability to post transactions to the next future period, or to 
current or past periods, as required. Properly classify and process this 
transaction activity. 


95. Permit a user-defined chart of accounts. Permit user modification when 
desired.- 


96. Provide- for use of a standard chart of accounts across all funds to enhance 
consistency in transaction coding and easy preparation of combining state¬ 
ments. 


97. Provide monthly trial balance reports that can be generated on an ad-hoc 
basis. 


■98.. Provide a periodic balance sheet with user-defined grouping of accounts, - 
user-defined titles, and user-defined totals. 


99. Provide a periodic statement of changes in fund balance with user-defined 
grouping of accounts, user-defined titles, and user-defined totals. 



!=Now, 


A=To be added, P=Partial or not as described, X=Not provided 
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Capability 

Vendor 

Status 

GENERAL ACCOUNTING/GENERAL LEDGER: 

100. Permit user-defined multiple funds. 


101. Provide capability for multiple preliminary closings before final closings. 


102. Provide automated closing of accounts to fund balance, under user control,, 
-‘"at year-end. . 


103. Provide a periodic control report with user-defined account groupings. 


104. Permit balance sheet accounts to be treated as restricted (no external 

entries allowed in specified control accounts) or unrestricted, as speci¬ 
fied by user. 


105. Provide a monthly report of analysis of fund revenue, with actual and 
budget revenue listed by revenue source. 


106. Provide a periodic listing of selected accounting transactions. 


107. Provide automated secondary fund accounting, with user-defined fund and 

general ledger account (enterprise funds, capital funds, etc.), on expendi¬ 
tures. 


108. Provide a monthly report of analysis of fund expenditures, with actual and 
budgeted expenditures listed by object. 


109. Accept back-dated transactions and post. 



* N'=Now, A=To be added, P=Partial or not as described, X=Not provided 
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5 Capability 

Vendor 

Status 

GENERAL ACCOUNTING/GENERAL LEDGER, continued: 


110. Close the user’s general books at the end of the normal accounting periods, 
under full user control. Permit user to close on any day following the end 
of a period. 


11-1. .-Allow for multiple posting runs for any posting period. 


112. Automatically generate double entry fund accounting from transaction coding. 


113. Produce audit reports upon request. These should be detail account analysis 
reports to allow reviewing all transactions for a particular account for a 
specified period of time. 


114. Maintain account history data for the current year and either one or two 
prior years at users' option. 


115. Provide ability to set up, through Chart of Accounts definition, special 
account records for internal costing purposes (i.e. in kind for another 
entity) with such records not reported for external financial statements. 


116. Permit posting to multiple months, multiple fiscal years. 


117,- Provide adequate information to support generation of cash, full accrual 
and modified accrual basis financial statements by fund. 


118. Provide financial statements, records and reports as required, including 
but not limited to: 


— Statement of Revenues, Expenditures and Transfers 
-- Balance Sheet 

— Trial Balance 

— General Ledger 

— Sources and Disposition of Funds 

— Internal Control Reports 



N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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Capability 

Vendor 

Status 

GENERAL ACCOUNTING/GENERAL LEDGER, continued: 


119. Provide capability to maintain and meet special accounting requirements for 
all types of funds including: 


— Governmental Funds 
— Enterprise Funds 
-- Internal Service Funds 
— Judiciary Funds 
- r -- Account Groups - 

— Special Revenue Funds 
-- Capital Project Funds 


120. Provide capability to perform accounting functions in accordance with 

generally accepted accounting principles for governmental agencies, includ¬ 
ing GAAP and MFOA guidelines. 


121. Provide a financial statement grouping capability. 


122. Provide capability to summarize individual line-item accounts into meaning¬ 
ful groupings of accounts for use in financial reporting. 


123. Provide capability to restructure account groupings without changing 
computer programs. 


124. Provide capability to carry forward appropriations at year-end in selected, 

, user-specified funds. 


125. Permit manual review of each encumbrance to determine whether funds should 
be carried forward to the new fiscal year. 


126. An amount approved for carrying forward to a new fiscal year should be 

combined with the current year approved budget amount for the appropriate 

account. However, amount carried forward also should be maintained . 

separately within the account. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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, Capability 

Vendor 

Status 

GENERAL ACCOUNTING/GENERAL LEDGER, continued: 


127. For appropriations carried forward from the previous year, appropriation 
checking should be performed separately against the current year budgeted 
amount and amount carried forward from the previous year. 

128. Provide monthly detail and summary reporting for expenditures charges to 
"appropriations carried forward from the previous year. 


129. Provide a rapid means of changing the data base to reflect changes in 

organization structure and to produce reports of such changes in a user- 
readable format. 


130. Process subsidiary ledgers with trial balances. 


131. Transfer funds intra-agency and inter-agency (revolving funds, payroll 
clearings) and generate a report showing all transfers. 


132. Journal entries generated should have debit-credit entries within an indi¬ 
vidual fund and relate same in other funds if they are involved. 

; 

* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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" Capability 

Vendor 

Status 

ENCUMBRANCES: 

133. Provide ability to record purchase orders, contracts and other planned 
future payments as encumbrances. 


134. Permit recording of encumbrances based on accounting structure. 


135..-'Encumber against account balance if funds available, if not, reject for 
user action. 


136. Permit modification of encumbrances (increase, decrease or reversal); 

generate appropriate accounting entries. Provide entries to the general 
ledger and to the open purchase order file to modify an encumbrance. 


137. Provide automated partial or complete liquidation of an encumbrance by 
payment against a claim/vendor invoice. 


138. Provide a list of open encumbrances upon user request. 


139. Refnstate selected open encumbrances from fiscal year to fiscal year. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 















Capability 

Vendor 

Status 

CONTRACTS: 


140. Provide special processing for contracts. 


141. For contract payments, enter all required information after verification 
of all invoices and supporting documents. The system should automatically 
__check the contract balance, reduce the balance by the amount of the payment 
• ”and authorize payment. 


142. Identify contract as executed and allow payments to be made when contract 
is executed. 


143. Reject and report disbursement requests in excess of remaining contract 
balance. Allow user override of rejection. 


144. Contracts encumbered when let. 


145. Optional assignment of a contract to a project (only one project is permit¬ 
ted). 


146. Provide ability to process contract change orders (increase or decrease). 


147. Permit disbursements (manual or mechanized) for progress payments or re- 
_ tainage. 


148. Maintain complete history of contracts; provide reporting on request until 
contract is deleted. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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< Capability 

Vendor 

Status 

DISBURSEMENTS: 


149. Provide for automated writing of checks (warrants). 


150. Provide multiple bank account disbursement capability. 


151. Provide ability to issue one check for multiple vouchers. 


152. Permit user to determine the maximum check amount to be written on the 

system. The user should also be able to hold payment at the invoice and/or 
vendor level. 


153. Provide automatic reversal of accounting distribution for voided checks. 


154. Provide automated support to check reconciliation process. 


155. Prepare a register of checks written. 


156. Print original and voided check numbers on the check register and check re¬ 
conciliation reports for audit purposes. 


157. _ Provide automatic restart procedures for the check printing routine. 


158. Accomodate manually issued checks and checks from other systems such as 
payroll. 


159. Provide the capability to record and report on manual checks written. The 
system should accept payment information, generate required journal entries, 
eliminate any encumbrance, adjust account balance, and enter check on 
check register and outstanding check file. The check register should pre¬ 
sent separately both manual and system-generated checks. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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venuur 

Status 

DISBURSEMENTS, continued: 


160. Write checks on request. Request specifies payment through a specific date, 
and specifies a topside limit on disbursements. 


161. Print no negative checks. 

- 

162. .-Provide ability to hold all payments for specified vendors, or specified 
invoices. 


163. Allow user to specify special routing/handling for checks and payments. 


164. Provide ability to hold or not to hold payment. 


165. Allow for due-date processing. The system should calculate due date from 
the invoice date and vendor terms. User should be able to override the 
calculated due date as required. 


166. Provide for optional check-writing less frequently than daily, e.g., bi¬ 
weekly. When producing checks, user should be able to specify a "pay 
through" date. System will then pay all items with a due date less than 
or equal to the "pay through" date, except for those items which have been 
flagged for special consideration. 


1.67. ~ Provide for producing one check for multiple invoices/credit memos. All 
invoices/credit memos due and payable to a vendor on a given payment date 
should be combined and paid with one check. The check stub or remittance 
advice should detail all items paid. 


168. Provide capability to check expenditures against monthly, year-to-date and 
annual budget. 


169. Re.iect transaction if total annual budget is exceeded; generate exception 
report. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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t . Capability 

Vendor 

Status 

PURCHASING/ACCOUNTS PAYABLE: 


170. Collect data concerning current and projected City expenditures and accounts 
payable, excluding payroll. Provide automated support to City purchasing 
operations. 


171. _Accept "one sided" entried and automatically generate offsetting entries. 

For example, when generating a check for Accounts Payable, also automatically 
generate all required accounting entries. In addition, all entries to con-, 
-‘trol accounts should be made automatically. 


172. Provide selective access to pending and past payments. 


173. Maintain open Accounts Payable records. Provide summary reporting of 

Accounts Payable by fund and account number for user in preparing accrual 
basis statements. 


174. Provide the ability to post voucher data to appropriate vendor records. 


175. Provide ability to interface with the general ledger, providing account 
validation, accruals, reversals, and journal entries. The system should 
also provide the ability to automatically generate accounts payable distri¬ 
bution and offsetting transactions under user control. 


176., Provide for cost requirements reporting including unpaid vouchers by vendor, 
and due date. 


177. Provide the user with a simple method of handling "One-Time" vendors. 


178. Permit any distribution error to be corrected by the user without having to 
back out the invoice and resubmit it. 


179. Provide 1099 reporting capabilities. 



N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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Capability 

Vendor 

Status 

PURCHASING/ACCOUNTS PAYABLE, continued: 


180. Allow specified payment date for invoices to take advantage of vendor dis¬ 
counts and/or payment terms. 

181. Provide vendor history retention capability. 


182. -'Treat intra-government billings as expended immediately with credit given 
to billing agency. •• 


183. Permit payment distribution to multiple accounts, including distribution 
to different cost centers, appropriations, funds and project/grants. 


184. Reject duplicate documents. 


185. Process credit memos. 


186. Provide interfaces with the General Ledger and other subsystems. 


187. Provide for processing of credit and debit memos to adjust the amount due if 
items are returned, or if an invoice is incorrect. 


188." Generate an exception report if invoices indicate that purchase order cost 
will be exceeded and a change order may be required. 


189. Maintain a Purchasing Commodity Catalog. 


190. Enter requisition on-line by line item. 



* N^Now, A=To be added, P=Partial or not as described, X=Not provided 
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' Capability 

Vendor 

Status 

PURCHASING/ACCOUNTS PAYABLE, continued: 


191. Accumulate total requisition cost from line item costs and compare the total 
cost to the account balance. 


192. Generate a monthly statement of purchase order balance for use by the user 
department and vendor. - 


193. Change orders (purchase orders or contracts): enter changes on-line. 


194. Automatically recalculate line item changed or added. 


195. Automatically calculate cost of change order and compare the total cost to 
the account balance. 


196. Adjust encumbrances; encumber added cost of change order if funds available; 
if not place change order in suspense for user action. 


197. Maintain open purchase order records against which receiving reports and 
invoices will be matched upon entry from Accounts Payable. 


198. Permit multiple account distribution on each PO. 


199.' Account for revenues by source. 



N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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vtMiaor 

Status 

ACCOUNTS RECEIVABLE/REVENUES: 


200. Provide a capability for automated entry of cash receipts data where received. 


201. Provide one common data entry transaction for all cash receipting. 


202. Provide for aging of accounts. 


203. Accounts receivable subsystem should include: receivables created from sales 
to outside customers. 


204. Receivables created from sales to other City agencies. 


205. Receivables created from agency enterprise operations. 


206. Complete interface with general ledger system. 


207. Provide flexible, user-defined aging criteria. 



N=Now, A=To be added, P=Partial or not as described, X=Not provided 

















" ’ Capability 

Vendor 

Status 

BUDGET: 


208. Provide capability to generate a pro-forma budget for each department having 
budget responsibility. Include budget totals and subtotals, and produce 
department and city-wide budget consolidations. These are to be retained 
in memory and be accessible to users. 


209. Provide capability for users to control the logic employed in generating 
pro-forma budget amounts for different line items, (e.g., users may 
"'need to specify an amount of zero for selected items, specify use of the 
previous year’s budget amount or amount actuaoly spent, or specify a factor 
to be applied to the previous year's amount.) 


210. Provide capability for users to receive a printed copy of the pro-forma 
budget. 


211. After budget approval, the corresponding stored pro-forma budget data must 
be accessible to other financial management subsystems, or be transferred 
as required, without need for reentry of data. 


212. Provide the capability for top-down budgeting starting at any organizational 
level above the cost center level, and for prorating budget units on the 
basis of previous years' or current year history. 


213. Provide for the budgeting of memorandum accounts. 


214.- Provide capability to modify original budget to accomodate any budget unit 
reorganization during the fiscal year; report original budgeted amounts 
under both the old and new structures. 


215. Support monthly budgeting (expenditure projections) by cost center, using 
any of three development methods at user's option: 


-- Annual amount allocated by month. 

-- Annual amount allocated by payroll cycle 
-- Budget specific amount for a specific month 



N=Now, A=To be added, P=Partial or not as described, X=Not provided 


















-40- 

Capability 

Vendor 

Status 

BUDGET, continued: 

216. Provide capability to change appropriations and expenditure projections 
at any time during the year. 


217. Permit cost center budgets to be summarized or rolled up by organizaton 
_structure, program.structure, and appropriation, as well as by fund. 


218. Permit three cycles to be tracked during the budget process: 

-- Estimated for current year. 

-- Requested for next year 
— Approved for next year 


219. Permit multiple budget iterations to be provided in each cycle. 


220. Report monthly pro-forma results of revenue and expenditure estimates for 
all funds and appropriations. 


221. Permit cost centers to be reassigned to new appropriations and/or funds 
without disturbing current-year processing. 


222. Establish budget for expenditures at the line item level; provide capability 
to control expenses at the line item, group of line items within cost ~ 

. center, and group of cost centers levels. 


223. Provide the capability for a budget summary report of line items by major 
class across all account structures. 


224. Provide capability to carry-forward residual prior year appropriations to 
the new year. 


225. Provide capability to budget by program and project, at user's option. 

_ 



* N-Now, A=To be added, P=Partial or not as described, X=Not provided 























• ' '* -41- 

Capability 

Vendor 

Status 

FINANCIAL PLANNING, MODELING AND FORECASTING: 


226. Provide capability to develop projections of future revenues and expenditures. 
Provide flexibility with respect to: 


— Organizational elements included. 


227.- “ — Line items included • 


228. -- Time period subdivision. Allow breakout by accounting period (month), 

by quarter, or by year. 


229. — Outpu Format. Produce printed output with selective inclusion 

of automatically generated subtotals and totals, corresponding 
to each line item. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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Capability 

Vendor 

Status 

FIXED ASSETS (if purchased): 


230. Maintain and update historical records of designated capital asset items by 
budget unit. 


231. Provide periodic reports to specified organizational elements indicating the 
Gapital assets that equal the element's General Ledger Capital Assets 

Account Balance. " . • 


232. Provide for maintenance of insurance replacement values; report periodically. 


233. Provide interface with accounts payable, (e.g., to reflect receipt of fixed 
assets) and other subsystems as required. 


234. Provide ability to record depreciation for internal reporting. 


235. Provide for accounting for fixed assets and for collection of maintenance 
and operating costs associated with those assets. Print summary reports 
to meet account and audit requirements. 


236. Maintain data concerning disposal of fixed assets. 



N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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t * Capability 

Vendor 

Status 

PAYROLL AND PERSONNEL (IF PURCHASED): 


237. Provide for collection and recording or employee information and tabular 
data to support payroll and personnel functions. 


238. Provide capability to implement multiple pre-tax and post-tax deductions in 
calculating amount withe!d and net pay. 


239. Provide computer-generated payroll checks. ’ 


240. Provide capability for manual issue of paychecks and posting of these to 
automated records. 


241 Provide for recording of a factor which relates each position to a full . 
time position in terms of prescribed work time. 


242. Provide capability for collecting time cost-tracking data and for record¬ 
ing of this data to support performance measurement, and support a program 
cost accounting subsystem if that is implemented. 


243. Provide capability for automated interface with other elements of the 
financial management system, such as expenditures records. 


244. Allow for multiple basis of time reporting (i.e., hourly, daily, monthly, 
weekly). 


245. Allow for daily, weekly, bi-weekly, semi-monthly, monthly and advance pay 
cycles. 


246. Permit multiple basis of distribution of labor costs (to include actual 
costs, applied costs to indirect costs, leave costs and benefit costs.) 



* K'-Now, A=To be added, P=Partial or not as described, X=Not provided 
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Capability 

Vendor 

Status 

PAYROLL AND PERSONNEL, continued: 


247. Support Automatic Deposit Reporting on an electronic medium. 

248. Support reporting for P.E.R.S. and FI.I.C.A. by electronic medium or 
printed copy. 


249. 'Print deduction and benefits reports. 


250. Provide for EEOC reporting. 


251. Provide ability to apply multiple hourly pay rates as required. 


252. Print W-2's. 


253. Print time sheets/cards/reports. 


254. Maintain vacation, sick and compensatory leave information. 


255. Allow user to machine print special pay checks (i.e. termination). 


256. Provide for position control and costing (e.g., to confirm only budgeted, 
approved positions are filled). 


257. Produce selective salary classification listings. 

_ 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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Capability 

Vendor 

Status 

PAYROLL AND PERSONNEL, continued: 


258. Permit integration of payroll date into existing special programs (e.g. CETA, 
WIN), with appropriate reports. 


259. Allow for multiple gross salaries to include taxable gross, total gross, 

F-.I.C.A. gross and other gross salary. 


260. Maintain both pay period and accumulative data YTD. 


261. Allow for benefits and deductions by individual, organization, or bargaining 
unit. 


262. Provide for issuing special pay or priority checks. 



* N=Now, A=To be added, P=Partial or not as described, X=Not provided 
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APPENDIX B 
VENDOR QUESTIONNAIRE 


CITY OF FORT WAYNE 
REQUEST FOR PROPOSAL 
FINANCIAL MANAGEMENT SYSTEM 
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APPENDIX B 

VENDOR QUESTIONNAIRE 


Vendors are requested to respond to each of the following questions 
and requests, using the space following each question. Attach continua¬ 
tion sheets as required. Include the completed questionnaire as Section 5, 
Volume III of the RFP response. 


GENERAL 

1. How can the City of Fort Wayne best validate the capabilities of the 
proposed system prior to selection? 


2. a. Will the vendor demonstrate the proposed system? 


b. If so, when and where? 


3. If selected as a "finalist", how does the vendor propose to present 
additional information to City management and technical personnel? 


4. a. What application software is available from the vendor, in addition 
to that proposed, which would be of potential value to the City? 
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b. To what extent can it interface with the proposed softv/are without 
modification of either? 


c. What is the number of current users of the proposed software? 


5. a. What "human engineering" features have been incorporated in the 
user's CRT interface with the system? 


b. What other system design features facilitate user training and 
acceptance, and enhance user productivity? 


6. Does the vendor have a users' group? If so, how many members? (Please 
identify a point of contact, with phone number.) 


IMPLEMENTATION - 

7. a. What acceptance tests does the vendor propose? (Indicate nature and 
scope.) 


b. Will the City participate in developing test files, and provide spe¬ 
cific transactions to be used in acceptance tests? 


8. a. What training will be needed for City user personnel? (Indicate sub 
jects, objective, and time required.) 
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b. For DP operations personnel having responsibility for CPU operation 
and program maintenance? 


c. Where, and by whom, will training be conducted? 


9. Is all required training included in the Proposal Cost Summary? (See 
Section IV, Paragraph 3b.) 


10. What City resources will be required in implementing the system? 


11-. What will be the City's responsibilities in support of system implemen¬ 
tation? 


12. What contract provision will provide assurance of timely delivery? 


13. In what language, and what version and level of that language are the 
programs written? 
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14. Is all proposed software, including identified optional software, now 
in existence (i.e., tested, degugged and in production)? 


15. a. Has the proposed software been developed to meet specific functional 
standards or requirements, i.e.. Restatement of GAAFR? 


b. If so, do functional capabilities comply fully with such standards, 
or are there exceptions? (List exceptions.) 


16. What file structure and access methods are employed? 


17. Are any program development aids (e.g., high level languages, screen 

development tools, debug tools) provided as part of the proposed package? 
(Identify, describe, and indicate origin and by whom they are supported.) 


18. Is a "report generator" module provided? Describe. 
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19. What security provisions exist to prevent unauthorized file changes and 
unauthorized access to data? 


20. What approach is used to providing data backup? 


21. a. Provide a brief overall description of the documentation provided, 
and its organization. 


b. Will the City be allowed to reproduce documentation to meet internal 
needs? 


22. a. Describe program maintenance documentation which will be furnished. 


b. Will all source code be furnished in machine-readable form? 

23. What are the provisions of the warranty covering software? 

24. a. Is an extended warranty, or continuing program maintenance support, 

available? 

b. What does it cover, and what is the cost? 
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25. What constraints do the initial or extended warranties impose on program 
changes made by the City? 


26. a. How is software maintenance provided? (i.e., what procedure does 
user follow? Is telephone consultation available?) 


b. What are the typical and "worst case" response times for software 
maintenance problems? (Time required to receive help which actually 
solves the problem.) 


27. If any of the following sub-systems have been included in the proposal, 
what would be the effects of their deletion? (Indicate for each sub¬ 
system the effect of its deletion on software costs, and any other effects.) 


a. Payrol1/Personnel: 


b. Utility Billing: 
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HARDWARE - 

28. a. On what makes and models of hardware has the proposed software been 
installed? 


b. Does the vendor currently offer these versions of the software? 


29. What are the proposed system's memory requirements? (Recommend that 
vendors use a continuation sheet to list all software components, in¬ 
cluding systems, development, and applications software modules. For 
each component, provide CPU memory and random access storage require¬ 
ments in bytes.) Indicate any assumptions (i.e. volumes, number of 
accounts) on which estimated file sizes are based. 
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APPENDIX C 

PROPOSAL COST SUMMARY 


CITY OF FORT WAYNE 
REQUEST FOR PROPOSAL 
FINANCIAL MANAGEMENT SYSTEM 


- 55 - 


APPENDIX C 

PROPOSAL COST SUMMARY 


TO: City of Fort Wayne 
City-County Building 
One Main Street 
Fort Wayne, IN 46802 
ATTN: Aaron Gluck 


The undersigned, being familiar with the requirements of the City of 
Fort Wayne Financial Management System Request for Proposal, proposes to 
furnish products and services to the City in accordance with that request. 

The summary below reflects projected City expenses for system acqui¬ 
sition and implementation. It may include cost estimates for items which 
the undersigned does not propose to furnish and which must be obtained 
from another source; these items are annotated accordingly. Items not so 
marked will be furnished by the undersigned at indicated costs. 

ITEM COST 

1. Application software and vendor- 
furnished support software, 

license.* _ 

2. Duration of application software 

warranty (months) __ 

3. Maintenance for application soft¬ 
ware for one year beyond end of 

warranty. _ 


4. Vendor on-site implementation 
support: 

User and DP training 


Other on-site support 


5. Other costs for City implementation. 


* Provide detail on other options, including annual license cost, in 
Section 4 of Cost Volume of RFP response. If software is available 
only under shorter term lease, include that cost in this summary and 
indicate the term. 
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In submitting this bid, it is understood that the right is reserved by 
the City of Fort Wayne to reject any and all bids, and to waive any infor¬ 
malities in bidding. 

The undersigned further states that this proposal is made in good faith 
and is not founded on, or in consequence of, any collusion, agreement or 
understanding between himself or any other interested party. 


OFFICIAL ADDRESS: 


FIRM NAME 


Signature of Principal 


PHONE: 


Title 


Date 











— IJ. 1 T UTILITIES r JRCHASE ORDER' ftA-OlO^’ 

DEPARTMENT REQUESTING ORDINANCE 


BOARD OF PUBLIC WORKS. 


*3-01-oA 


SYNOPSIS OF ORDINANC E City Utilities Purchase Order #A-010412 for an Automated 
Financial Accounting System for the Fort Wayne City Utilities. The bid received from 


American Management Systems, Inc, was the only bid'received. After close evaluations 

and a review of other systems it was determined that this system is the best 


system for the funds available. ' The' City Utilitie s'accounting system is manual at 

system “ ! - - ------ 

present; with an automated accounting there would-be-better control of dollars 


spent. 


EFFECT OF PASSAG E City Utilities Operations (Accounting) would have an Automated 
Finanacial Accounting System. 


EFFECT OF NON-PASSAGE The above P.0, will not be processed. 


MONEY INVOLVED (DIRECT COSTS, EXPENDITURE, SAVINGS) $167, 5)0 


ASSIGNED TO COMMITTEE 


























































